API Aggregation Layer

#cloud-native #knowledge #architecture #kubernetes/cluster/extend

개요

집계 레이어.^[1]
이건 쿠버네티스를 더 확장하고자 할 때, 그것도 기본적으로 제공되는 api 이상으로 확장시키고 싶을 때 사용한다.
이것을 사용하는 대표적인 쿠버네티스 솔루션이 바로 메트릭 서버이다.
이것은 kube-apiserver가 새로운 오브젝트를 받아들이게 하는 CRD와 다른 개념이다.

왜 집계(Aggregation)이라 부르는가?
작동 원리를 보면 알겠지만, 이 레이어가 존재하는 이유는 우리의 커스텀 api서버를 만들기 위해서다.
이 레이어가 일단 모든 트래픽을 받아서 처리하기에 집계한다고 표현하는 것이다.

작동 원리

이 레이어는 api서버 내부 프로세스에서 프록시로서 동작한다.
우리가 원하는 api를 등록하려면 [[#APIService]]라는 오브젝트로 해당 경로를 요청(claim)하면 된다.
그러면 집계 레이어가 사용자가 지정한 api로 들어온 요청을 프록시하여 APIService가 원하는 경로로 보내줄 것이다.
프록시로 서있기 때문에 집계 레이어라고 부르는 것이다.

이 APIService를 사용하는 흔한 방법 중 하나는 클러스터 내부에 파드를 하나 두는 것이다.
나만의 api 서버를 만들었으니, 기존 api서버를 확장했다고 하여 확장 api서버라고도 부른다.
그래서 이 나만의 api서버가 특정 api 요청을 수행하도록 하는 것이다.
웬만해서, 이 api 서버는 실제 kube-apiserver와의 레이턴시가 5초 미만일 것이 권장된다.

인증 플로우

기본적인 방식이라고 한다.^[2]
CRD는 기존의 api서버를 이용하지만, 이놈은 프록시를 통해 나만의 커스텀 api서버로 트래픽을 보내는 방식이다.
그래서 이 두 서버간의 통신이 안저나게 이뤄지기 위해서 x509 인증서가 활용된다.
차근차근 순서를 보자(OIDC가 엄청 어려운 개념까진 아니지만, 현재 설명 상에서 걸리적거려서 제외한다).

유저가 기본 api서버에 적합한 인증서를 들고 요청을 보낸다.
api서버는 일단 먼저 인증을 하고, 쿠버 RBAC로 권한까지 체크한다.
문제가 없으면 aggregator가 커스텀 api 서버에 mTLS를 위해 클라 인증서와 키를 사용해 세션을 연다
- 헤더에는 사용자 정보를 추가해서 보낸다.
커스텀 api 서버는 인증인가를 거친다.
- 인증인가를 위해 kube-system 네임스페이스에 있는 ConfigMap을 사용한다고 한다.
성공적이면 성공적이라고 리턴한다.
이후에 승인(admission) 체킹을 하며 유효한지, 추가적으로 붙일 것이 있는지 체크를 한다.

APIService

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: <name of the registration object>
spec:
  group: <API group name this extension apiserver hosts>
  version: <API version this extension apiserver hosts>
  groupPriorityMinimum: <priority this APIService for this group, see API documentation>
  versionPriority: <prioritizes ordering of this version within a group, see API documentation>
  service:
    namespace: <namespace of the extension apiserver service>
    name: <name of the extension apiserver service>
  caBundle: <pem encoded ca cert that signs the server cert used by the webhook>

Apiservice라는 놈은 이렇게 만든다.

참고

아마 이 문서는 내가 직접 확장 api를 만들어볼 때나 조금 더 구체화시킬 것 같다.